Обсуждение:Язык программирования

.NET

.NET — это не язык программирования, а технология. Имхо, здесь ему не место.

Да ты не стесняйся — убирай если видишь что не в тему. А ещё лучше — правильное вставляй :) И подписывайся в комментах, вот так: MaxiMaxiMax 12:13, 28 Июн 2004 (UTC)

Русификация названий языков

Есть ещё несколько языков, названия которых вполне можно писать по-русски:

Forth → Форт
Simula → Симула
Occam → Оккам
Delphi → Дельфи
Erlang → Эрланг

Форт и Симула точно встречались в советских книжках. — Monedula 10:22, 1 августа 2005 (UTC)

Да, это так, Форт и Симула писались в советских книжках по-русски. Однако, в настоящий момент налицо тенденция записывать названия языков программирования по-английски. И по-моему это довольно правильно. Можно провести аналогию с латинскими названиями в медицине и биологии. Их никогда не транскрибируют, предполагая, что читатель достаточно подготовлен, чтобы прочитать латинские буквы. Латинское наименование служит в этом случае единым идентификатором, исключающим любые разночтение. В программировании роль латинского языка несомненно принадлежит английскому. По этой причине я полагаю, что такие вещи, как названия языков и технологий, нужно записывать в их исходном виде - по-английски.

Кроме того, как я уже писал в более общем обсуждении, в случае Форта, Ады и Джавы/Явы мы получаем ложные смыслы:

* Язык Форт не имеет отношения ни к форту-крепости, ни к фортификации, ни вообще к военному делу

* Язык Ада - это не язык, на котором общаются черти

* Язык Ява никак не связан с сигаретами. А вот с кофе - связан, но русское слово Ява с кофе не ассоциируется --evgop 11:08, 1 августа 2005 (UTC)

В биологии латинские имена не заменяют русские, а только дополняют их — обычно латинское название пишут в скобках после русского. А «ложными смыслами» вообще мало кто заморачивается — ведь живём же мы с таким словами, как «ключ» или «лук». — Monedula 12:04, 1 августа 2005 (UTC)

Вы оба правы. Надо лишь решить, что соответствует целям Википедии. Ramir

Определение

По-моему определение : "....Язык программирования – формальная знаковая система, предназначенная для описания алгоритмов в форме, которая удобна для исполнителя (например компьютера)...." не совсем правильное. Если бы мы писали алгоритмы в форме, удобной для исполнителя, то мы бы писали вот так 00111011011101110111....

Абсолютно согласен. Да и удобство - понятие весьма субъективное.. Зато не указано, что ЯП испольуется для создания программ для ЭВМ. И почему "_например_ компьютера" ?? Есть языки программирования НЕ для компьютеров??? А под текущее определение подпадают например блок - схемы, которые мы рисовали на уроках информатики..

Конечно есть. Те же микроконтроллеры сложно назвать компьютером. Goryachev 15:00, 27 января 2010 (UTC)

• Есть вполне рабочее определение из стандарта ИСО 2382-1 "Information technology -- Vocabulary"

01.05.08. Язык (в программировании)

Множество Литер (01.02.11), условных знаков и правил, которые используются для передачи Информации (01.01.02).
01.05.09. Естественный язык
Язык (01.05.08), правила которого основаны на текущем использовании без их точного предварительного описания.
01.05.10. Искусственный язык
Язык (01.05.08), правила применения которого точно установлены до начала его использования.
01.05.11. Язык программирования
Искусственный язык (01.05.10) для точного описания Программ (01.05.01).

--Dingecs 16:37, 27 января 2010 (UTC)

На английской википедии ни слова про лексику. Язык состоит из синтаксиа и семантики. Какая из версий врёт? The description of a programming language is usually split into the two components of syntax (form) and semantics (meaning), which are usually defined by a formal language

Никто не врёт, имеет место некоторая избыточность. В данном случае лексика просто является частью синтаксиса. Евгений Мирошниченко 14:34, 31 января 2022 (UTC)

Mesa - не язык

The Mesa 3D Graphics Library Интересно, какой троль его сюда занес ? Уберу его, как выше советуют. --Evgen2 23:20, 29 марта 2006 (UTC)

Mesa - язык

Смотреть надо внимательнее, прежде чем лезть с правками очертя голову. S.Felix 08:48, 20 декабря 2006 (UTC)

Удивительное рядом

Один C, один C++ и два бейсика - qbasic и Visual Basic. Может таки это разные реализации одного языка и стоит заменит на просто Бейсик ?--Evgen2 23:33, 29 марта 2006 (UTC)

Это два разных языка. Не стоит их удалять.

Почему не подписываемся ? Почему разные языки ? и чем qbasic таким особенным от gw-бейсика или турбо-бейсика или что там еще было отличается ? А почему MS QC1.0 и, например, Analog Device C for DSP - это один язык ? И с паскалями тоже кстати. Не надо путать отличия в реализациях, версиях, диалектах и языках. Во! был же еще ВАСИК! В котором все команды были на русском. Еще то чудо ;-)--Evgen2 17:00, 30 марта 2006 (UTC).

Забыл подписаться. А разница между qbasic и Visual Basic заключается хотябы в том, что программу написанную во втором не скомпилится компилятором первого. Плюс, насколько я помню QBasic не имеет никакой обьектной модели, да и вообще разница между этими языками достаточно велика. --EvilBot 17:21, 30 марта 2006 (UTC)

Ну так «программу написанную во втором не скомпилится компилятором первого» - стандартное явление в C/C++, Паскалаях, Ассемблерах и т.п., больше того, может оказаться что и компилятор один, и программа одна, а вот фигвам, потому как «разные ключики», например - 16 бит и 32 бита. И процесс есть борьбы с этим - Портирование называется. --Evgen2 09:13, 31 марта 2006 (UTC)

Ну это конечно была грубая аналогия. Но а остальные мои аргументы имеют право на жизнь? --EvilBot 09:37, 31 марта 2006 (UTC)

Имеют, почему не имеют. Но я б все-таки из списка языков программирования убрал qbasic - он точно подходит под диалекты basic'а (и я что-то из этой оперы еще помню ;-)). Плюс эээ..вот раз в списке есть sh как язык программирования - это как бы несколько неправильно, потому как оно коммандный процессор. Тогда надо в список добавлять command.com из dos с языком бач(бат)-файлов, cmd.exe и 4os2 из OS/2 и много всякого прочего. По идее, если есть энтузиазм - надо отдельно дать описание коммандных процессоров и используемых ими языках, которые близки к скриптовым, но не совпадают с ними полностью. --Evgen2 17:36, 31 марта 2006 (UTC)

Компилируемые и интерпретируемые языки

Неправильно говорить, что языки являются компилируемыми или интерпретируемыми. Такими бывают реализации языков, а не сами языки. См. Programming language implementation в английской википедии. Это относится и к статье «Программирование» --Anton Khorev 16:59, 18 августа 2006 (UTC)

• Полностью согласен. И весь параграф стоит переписать соответственно. Более того, языки могут быть реализованы как интерпретаторами, так и компиляторами. И практически всегда остаётся немного "остаточной интерпретации".--myke 11:24, 10 февраля 2010 (UTC)

Сомнительно

"Расширение набора используемых символов сдерживается тем, что многие проекты по разработке софта являются международными." Всё с точностью до наоборот. — Тжа0.

А поподробнее можно? — Monedula 16:51, 22 июня 2007 (UTC)

Честно говоря, не ожидал от Вас такой тормознутости, хотя с гс2пу-лингвистами у меня давно нелады. Вы, как басенный герой, — «слона-то я и не приметил»/<з/…>/…. Это же концепт вики: тем больше людей участвует — тем больше новых идей и тэстинга. — Тжа0.

...И тем больше ограничений. — Monedula 17:39, 22 июня 2007 (UTC)

Ладно, Вас не переубедиш: хоть кол на голове теши/<…>. Ограничения убираются: об этом вся история компъинженерии. — Тжа0.

Откат

Откатил строчку "В современном мире самыми популярными языками программирования являються:Paskal,C++,Delphi": не обосновано (я считаю утверждение ложным) (кроме того, две орфографические ошибки). Sasha1024 19:43, 25 декабря 2007 (UTC)

Cтатья Крис Касперски - Языки, которые мы потеряли -- весьма безграмотна

Статья Крис Касперски - Языки, которые мы потеряли содержит массу принципиальных ошибок, которые постоянно приводят автора к весьма неадекватным выводам.

В целом, статья написана чрезмерно живым и эмоциональным языком, и посвящена, что кстати идёт вразрез с её названием, по большей части (технически безграмотному и логически необоснованному) доказательству ущербности языка C++, да и людей, программирующих на нём. Я полностью согласен с автором в том что знание математики и вдумчивый анализ алгоритмов и программ - одно из лучших средств борьбы за эффективность и надёжность и в том, что язык программирования C++ - конечно же не есть лучший инструмент на свете для решения любых задач и ООП вообще сегодня зачастую оказывается сильно переоценено! Но основные проблемы и ограничения языка и его практического применения освещены в целом неверно. Не стоит всё таки аргументировать за что-либо подобным способом!

Вот несколько примеров.

Первый ляп - первое же предложение после вступления: «Язык Си++ (а вместе с ним и его многочисленные «преемники») уже давно не является объектно-ориентированным языком и доэволюционировал до метапрограммирования, более известного как программирование с использованием шаблонов».

Вообще-то метапрограммирование - «создание программ, которые создают другие программы как результат своей работы» - никак не совпадает с «обобщённым программированием с помощью шаблонов» (как называет его Бьерн Страуструп). Функциональное метапрограммирование с использованием шаблонов в C++ - лишь частный побочный эффект возможностей, предоставляемых шаблонами, совсем не обязательный при обобщенном программировании и применяемый на практике довольно редко.

«... шаблон вообще ничего не знает ни о типах, ни о размерностях. Он просто обращается к методам соответствующих классов, которые могут быть реализованы как угодно либо же не реализованы вовсе, и тогда программа даст сбой. До тех пор пока использовались только статические абстрактные типы, «перекладываемые» на машинное представление еще на стадии компиляции, транслятор легко отлавливал подобные ошибки, но с появлением динамических типов, обрабатываемых в реальном времени, язык стал вообще неконтролируемым и программы начали падать в случайное время.»

Цитата свидетельствует о том, что автор явно полностью не понимает механизм шаблонов в C++ (зато питает к нему выраженную антипатию)). Шаблоны C++ - механизм чисто статический (т.е. поведение, определяемое ими, "как и в старые добрые времена" всегда уже полностью сформировано к моменту начала выполнения программы). Если метод класса, используемый в шаблоне не определён - это вызовет ошибку компиляции, но никак не сбой в runtime (если метод определён, но правильное поведение в нём не реализовано - это банально грязный недописанный код, вероятность появления и "использования" которого абсолютно не зависит от применения ООП или шаблонов). Полиморфизм (все средства ООП) и шаблоны в языке C++ - независимые механизмы, не опирающихся друг на друга, хотя и наиболее полезные при совместном применении. Другими словами вполне можно представить себе Си с шаблонами или C++ без них.

Замечу от себя, программируя уже более 7 лет на с, C++, java и других объектных, необъектных и функциональных языках и поневоле сравнивая их между собой, могу сделать вывод, что основная сложность и "опасность" языка C++ проистекает как раз из стремления сохранить в нём весь "старый добрый" низкоуровневый арсенал - неинициализированные данные, неконтролируемые указатели, ручное распределение памяти, "сырое" приведение типов и прочее. Именно необходимость уживаться с этими средствами способствует легкости совершения на этом языке каверзных, незаметных и труднодиагностиремых ошибок, особенно для новичков.

«... язык (C++) настолько обширен и объемен, что его изучение требует невероятных усилий. Чтобы окупить средства, вложенные в разработку компиляторов, фирмы вынуждены «подсаживать» на него миллионы программистов, которые, пройдя длительный (и ужасно мучительный) путь обучения Си++, просто не могут признаться себе в том, что напрасно убили десять лет своей жизни (данной человеку лишь однажды!) и что стоящие передними задачи с ничуть не меньшей эффективностью реализуются на чистом Си и других процедурных языках, легко осваиваемых на ходу без отрыва от производства. Вот они и начинают убеждать остальных, что процедурные языки давно мертвы. Сложность ради сложности.».

Это тоже по-просту не так. Затраты на базовое, но вполне адекватное освоение C++ практически равны сумме затрат на базовое освоение языка Си и основных концепций ООП. Проверено не раз, в том числе и на себе. К тому же C++ - процедурный язык, он обладает почти полной обратной совместимостью с Си, так что говорить о принципиальной сложности изучения или применения C++ по сравнению с Си просто бессмысленно (ведь никто в конце концов не заставляет автора использовать именно ненавистные ему полиморфизм или шаблоны). Именно такая простота освоения и обратная совместимость (а не глобальный заговор корпораций)) способствовала быстрому и широкому распространению языка C++.

Итак, статья представляет собой неприкрытый флэйм чистой воды, не достойный упоминаться здесь. Удаляю ссылку. — mas 195.34.254.6 19:06, 20 мая 2008 (UTC)

Новый язык программирования "Church"

Прочитала в инете про новый язык программирования. Вот сЦылочЧкО (ссылка убита мной как спамерская --Bilderling 10:40, 2 апреля 2010 (UTC)) Можно его добавить в список языков?

С уважением, ТанечЧкО 217.132.109.3 09:18, 2 апреля 2010 (UTC)

Что-то совсем мало информации по вашей ссылке написано. Я так и не понял что за язык. Но было бы здорово, если бы вы написали о нем статью. -- X7q 09:44, 2 апреля 2010 (UTC)

А я это ... писать не умею типо. В третьем классе мАзги свои на булочЧку променяла 217.132.109.3 10:32, 2 апреля 2010 (UTC)

Коллеги, это спам/троль. В нескльких обсуждениях одно и тоже, надо откатывать сразу. --Bilderling 10:39, 2 апреля 2010 (UTC)

Редактирование раздела См. также

Думаю, будет полезно указать в розделе [См. также] викиссылку на страницу Прогопедия — энциклопедия языков программирования. Стоит ли ее ставить, а если стоит, то вместо чего ее можно поставить? Розширяя (удлинняя) колону получится просто нагромождение текста. — SerjHL 22:22, 12 августа 2011 (UTC) фигня полнейшая. Viadous 23.05.2013

Языки программирования компьютеров. (андроид)

Не так?:http://img-fotki.yandex.ru/get/9151/42727503.4/0_79aae_462fa9d6_L.jpg

91.205.25.131 03:03, 13 октября 2013 (UTC)

Популярность языков

Надо добавить

• Из раздела «популярность» была вандалистически удалена подкреплённая источником обзорная характеристика популярности C++:

язык C++ на протяжении десятилетий входит в число лидеров популярности по количеству учебников, вакансий, упоминаний и др. Как отмечают скептики, причина этого в том, что принципиальная невозможность стабилизировать язык держит программистов на нём постоянно занятыми, и это, с одной стороны, заставляет компании-разработчики ориентироваться на найм C++-программистов (повышая число вакансий, и, как следствие, побуждая новичков изучать его), но с другой, резко удорожает разработку в целом; кроме того, изобилие книг по C++ имеет причинами как изобилие присущих ему технических проблем, так и обособленную уникальность принятого в сообществе понимания фундаментальных понятий информатики (абстракции, инкапсуляции и др.) и принципов разработки, но книги учат обходить проблемы C++ и принципиально не способны их устранить.

Этот абзац (не обязательно тождественно) должен здесь быть. Пояснения:

1) Статья относится к фундаментальной научной дисциплине, и критерий «популярности» на самом деле ни прикаких обстоятельствах не должен приниматься в расчёт техническим специалистом при выборе инструмента (ни в науке, ни просто в инженерном деле нет места критериям вроде «миллионы леммингов не могут ошибаться»). Однако, на практике этот критерий принимается в расчёт настолько часто, что даже сформировалась методология вокруг него и возникли тематические сайты. Соответственно, это заблуждение должно попасть в энциклопедию, и оно (заблуждение) должно быть акцентировано и обосновано. Обоснованием в данном случае является противопоставление: примеры технически убогих языков, лидирующие по популярности. Ярчайших примеры — C++ и Кобол — они используются очень много, но совершенно зря. Вообще, по разным источникам, худшие в массовой промышленности языки — C++, Кобол, ПЛ/1, Ада, Фортран, плюс с оговорками упоминаются Forth, APL. Первые два в качестве примеров для обзора идут идеально, а двух примеров здесь вполне хватит.

2) Источники, подтверждающие саму критику, в изобилии собраны и систематизированы (но опубликовать статью пока мешает численный перевес предвзятых участников над грамотными в рувики, так что придётся сперва довести её до статусной в англовики, а затем просто перевести и поставить перед фактом). Тащить сюда ворох источников будет нарушением баланса статьи — здесь идёт лишь обзор. Я выбрал один источник, хорошо проходящий по критерию авторитетности; это не «мнение», он идёт в качестве примера. Пояснение к правке было «заведомо хейтерский». На самом деле, работа имеет копирайт и издана в трёх изданиях, публикуется на университетских сайтах. В ней идут ссылки на множество других источников, то есть служит обзорной сама по себе. Всякий параграф в ней предваряется общетеоретическими сведениями, уже без ссылок, но то же самое можно при желании найти у Хоара, Вирта и прочих — то есть это объективный, скрупулёзный анализ, а не поругательство. Работа обширно цитируется — если спросить на серьёзном форуме про критику C++, то именно она будет среди первых ссылок (пример).

Категорически настаиваю на присутствии критики C++ в этом разделе статьи. Конкретное изложение ещё можно подработать. Arachnelis (обс.) 23:40, 26 ноября 2016 (UTC)

• В статье «Языки программирования» в разделе «Измерение популярности языков» внутри оговорки про отсутствие прямой связи популярности и качества этот огромный кусок про особенности C++. Полагаю, это должно в переработанном виде пойти в статью C++, а не сюда. Здесь можно только сказать пару слов, и отталкиваясь не от языка, а от критерия (вакансии, книги), и только вскользь упомянуть в этой связи C++ с чёткой ссылкой на источник. — Джек, который построил дом (обс.) 00:53, 27 ноября 2016 (UTC)

• Не спорю. Предложите свою формулировку. Я старался передать максимально близко к формулировке из источника, а то меня в своё время слишком много обвиняли в отсебятине. Arachnelis (обс.) 09:01, 27 ноября 2016 (UTC)

• Вот такой урезанный вариант:

язык C++ на протяжении десятилетий входит в число лидеров популярности по количеству вакансий, учебников и упоминаний, но его использование оборачивается огромными убытками, а книги преподают обособленную, уникальную трактовку фундаментальных понятий информатики[1]

Arachnelis (обс.) 17:58, 27 ноября 2016 (UTC)

• Если в источниках ничего не говорится о популярности C++ в связи с качеством, то вынужден согласиться с мнением на Википедия:Форум/Вниманию участников#Популярность языков программирования о том, что это орисс. В приведённом отрывке орисс выдаёт слово-связка «но». Такие слова-связки возможны между атрибутированными мнениями, а не между их содержаниями («Язык C++ входит в число лидеров по популярности^[1], но его использование оборачивается огромными убытками^[2]», «Язык C++ входит в число лидеров по популярности^[1]. В то же время критики указывают на то, что…^[2]»). Первое точнее называется «оригинальный синтез»; наиболее подробно об этом написано на en:WP:SYNTH. — Джек, который построил дом (обс.) 20:51, 27 ноября 2016 (UTC)

• Я хотел как проще, но получается как всегда. Зайдём с другой стороны — у нас есть обильная критика C++, временно не допущенная к публикации (умру, но дотолкаю). Если бы она уже была опубликована, можно было бы просто сказать «C++ популярен[1], но ужасен — см. критика C++». Здесь проблема в том, что «см.» нечего. Поэтому в качестве временного же решения надо синтезировать некое предложение, взяв из имеющегося черновика пару фраз и их источники. Ваши варианты? Arachnelis (обс.) 14:20, 28 ноября 2016 (UTC)

• В прочем, стоп. У Джойнера есть строки и про популярность, и про убыточность его применения, так что орисс исключён. Соберу другой вариант, только в рефе придётся страницы через запятую перечислять. Arachnelis (обс.) 14:28, 28 ноября 2016 (UTC)

• Вопрос в весе самого Джойнера за пределами статьи C++. Если мы пишем про языки вообще, то и текст нужен про языки вообще. --be-nt-all (обс.) 14:47, 28 ноября 2016 (UTC)

• А как же примеры? Где речь не о голой математике, нужна конкретика. Вот я выписал несколько предложений из Джойнера, можем дружно скомпилировать их в предложение, которое бы всех устроило.

(p.1) One desired outcome of this critique is that it should awaken the industry about the C++ myth and the fact that there are now viable alternatives to C++ that do not suffer from as many technical problems. ... The alternatives to C++ provide no silver bullet, but significantly reduce the risks and costs of software development compared to C++. The alternatives do not suffer under the complexities of C++ and do not burden the programmer with many trivialities which the compiler should handle; and they avoid many of the flaws and inanities of C/C++. ... C++ has become even more widely used over the last few years. (p.58) The concluding advice of this critique is clear. Be wary of C++.

(p.44-45) This headline comes from Cutter Information Corps “Object-oriented Strategies” May 1996 edition. Based on their findings, C++ accounts for 80% of all OOLs. ... Measured C++ sales are riding on C’s success. ... One way a manager might perceive C++ to be a winner is the sheer number of books one sees in a bookshop on C++. This is matched by a huge number of courses. An observation about the nature of many of these books is that they are often titled something like “How to build a widget in C++,” or “Compiler Construction in C++.” “Books appear like mushrooms after rain” [Plauger 93]. The mushrooming book market is a great boon for publishers ... Many C++ books are on how to avoid the traps and pitfalls, and develop rigorous coding standards, which might appeal to management as the solution, but they don’t solve the root cause of the problem. ... [Sakkinen 92] observes the “Endemic C++ Culture.” He notes that too many courses on “design” have the appended clause “with C++.” This is because C++ has its own curious terminology...

(p.42) I have already heard stories of C++ tool vendors complaining that the standard is too horrendous to understand, and then to implement anything compliant. Standardisation should stabilise the specification, but C++ has continued to become less stable. The fact that the C++ standard is so unstable indicates that the C++ committee realises there are many shortcomings in C++ that they must rectify. There are many flaws that the committee knows about that I do not cover in this critique, but also many of the flaws that are covered in this critique, the committee have no intention of addressing, as that would break too many existing programs and C compatibility.

(p.43) The C++ community seems to think using a fundamentally flawed tool is acceptable and that the rest of the world must wait for them to straighten these issues out, which in many cases isn’t even possible. It is also a hidden cost to companies that their programmers must continually keep up to date, and abreast of the arguments for and against certain constructs. Many other languages have solved these problems. ...

(p.43) [Stroustrup 94] has the following to say: “... Because of C++’s emphasis on static type checking, much of the increase in complexity has appeared in the form of language extensions.” ... P.J. Plauger in [Plauger 93] argues that the complexity of C++ has put it on par with PL/I, Ada (83) and Algol 68. He does not accept the complexity in C++ as a good thing. Criticising the complexity of Ada is somewhat unfair. An amount of Ada’s complexity is due to its support of multitasking and real-time programming.

(p.44) C++’s complexity is not solely due to static type checking. Eiffel is more strongly type checked than C++, but doesn’t suffer from the same complexity ... Complexity is not the necessary companion of seriousness.

(p.57) Today’s C++ programs will be tomorrow’s unmaintainable legacy code. As [Unix-Haters] say of C++: “The seeds of software disasters for decades to come have already been planted and well fertilised.” They compare C++ to COBOL in terms of unmaintainable legacy code which we have now in COBOL’s case, and we will have in the future for C++.

Перескажу ключевые тезисы (для тех, кто не очень дружен с аглицкой мовой, или просто не уследил среди многабуков). Для удобства соотнесения с оригиналом не сортировал, выписываю по порядку следования:

1) Сабж. В единой работе автор пишет, что C++ аццки популярен, но объективный анализ показывает, что от него необходимо полностью отказаться. Более того, такие акценты, как использованное слово "миф", подкрепляют существование самого абзаца о том, что "популярность не есть крутость".

2) Популярность. C++ настолько популярен, что даже приходится убеждать толпу, что ему-таки есть альтернативы, резко сокращающие стоимость и риски. Более того, по официальным данным, доля кода на C++ составляет 80% от всего ООП, но есть основания полагать, что это код на Си в некоторой окаймовке C++, а следовательно, что наблюдаемый успех C++ просто паразитирует на реальном успехе Си. Книги же по C++ множатся как грибы после дождя.

3) Заблуждения. C++ имеет обособленную (endemic, curious) культуру — что, разумеется, не замечается его адептами, гордо восседающими на вершине популярности. Это также имеет двустороннюю связь с изобилием книг на полках магазинов: продаётся слишком много книг по «дизайну на C++», а не по «дизайну программ в отрыве от языка», что как раз и ведёт к искажённому восприятию адептов языка — они уверены, что C++ является Вершиной Достижений Информатики и другие языки должны подминаться под совместимость с ним, и не хотят видеть сущностную ущербность исходно заложенного подхода.

4) Убытки. Поскольку язык битый в своей основе, и зрелого состояния достичь не может физически (у комитета по стандартизации и вендоров компиляторов проблем даже больше, чем у пользователей языка), то его использование оборачивается огромными убытками, так как кодеры вынуждены постоянно поддерживать код, который на других языках уже давно бы работал и не требовал поддержки.

5) Сложность. Здесь C++ стоит в одном ряду с PL/1, Ada и Алголом, хотя сравнение с Адой нечестно, так как она предоставляет возможности, отсутствующие в C++. А вот сложность C++ ничем не оправдана. Страуструп списывает её на статическую типизацию, но другие альтернативы демонстрируют обратную закономерность. И уж тем более сложность — не то же самое, что серьёзность, хотя Страуструп пытается выдавать одно за другое — дескать, чем сложнее, тем серьёзнее.

6) Соотнесение с Коболом (Джойнер перецитирует UnixHaters — которых много и они вообще аццкая элита — соответственно, укрепляет связь в статье с примером Кобола): то, что код на Коболе неподдерживаем, идёт как прописная истина, а C++ — это новый Кобол.

Итого вариант формулировки:

C++ входит в число лидеров популярности по нескольким показателям, но из-за множества присущих ему технических и субкультурных проблем его использование оборачивается огромными убытками^[1]

• Arachnelis (обс.) 17:03, 29 ноября 2016 (UTC)

Кто такой Ian Joyner

• Кто такой Ian Joyner, кто нибудь может объяснить? Также не понятно, почему критика 1996-го года безукоризненно принимается, когда с того времени прошло 20+ лет, в 1996 году язык даже не имел стандарта, и принципиально изменился с времен даже C++98. В научной литературе источник цитируется всего 3 раза. Кто рецензировал данный источник? Это больше похоже на какого-то динозавра-самиздата. Bsivko (обс.) 19:21, 30 ноября 2016 (UTC)

• Главное здесь то, что за это время язык только хуже стал (можно порыться на счёт этого утверждения в более свежих критических АИ, но сил нет). Даже есть фольклор: "число 11 в названии C++11 - это число ног, которое они пришили к C++ для получения более совершенного спрута". Arachnelis (обс.) 19:28, 30 ноября 2016 (UTC)

• Позволяя себе подобные пассажи, вы рискуете получить большие проблемы по ВП:НЕТРИБУНА. Если вы не можете взвешенно и нейтрально говорить о языках программирования, то эту тему лучше вам не трогать. Bsivko (обс.) 19:42, 30 ноября 2016 (UTC)

• Данный "пассаж" подкреплён, если хотите, источником C++ FQA. А написанная мной более чем наполовину статья Язык программирования, если вы не заметили, как раз очень взвешенна и информативна (что в случае с обзорной статьёй само по себе является синонимом взвешенности), и последнее как раз даёт мне право не просто говорить, а диктовать эту тему. И тем не менее, я этого не делаю, а просто настойчиво добиваюсь присутствия объективной информации в публичной энциклопедии. Arachnelis (обс.) 21:46, 7 декабря 2016 (UTC)

• А то, что он ВООБЩЕ в научной литературе цитируется - уже ОЧЕНЬ КРУТО для источника, имеющего отношение к C++, т.к. другой АИ прямо утверждает, что в научной литературе ОЧЕНЬ РЕДКО встречаются ссылки на литературу по C++. upd: Пардон, Джойнер сам этот источник перецитирует, с.56. Arachnelis (обс.) 19:30, 30 ноября 2016 (UTC)

• 3 цитаты за 20+ лет это ниочём. Bsivko (обс.) 19:39, 30 ноября 2016 (UTC)

• По факту, с учетом ВП:ВЕС, мы имеем в лучшем случае:

По мнению Яна Джойнера (евангиелиста языка Eiffelist и платформы Mac?), C++ в середине 1990-х входил в число лидеров популярности по нескольким показателям, и, по его заключению, из-за множества присущих ему технических и субкультурных проблем его использование оборачивалось огромными убытками.

И данная цитата ещё не факт, что проходит ВП:АИ, а также может быть помещена только в контекст критики C++ (т.е. только в статью C++ и только в её раздел критики). Bsivko (обс.) 19:36, 30 ноября 2016 (UTC)

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

• Это уже ваш орисс, и чтобы опровергнуть это, вы должны доказать, что язык стал ЛУЧШЕ и критика Джойнера ПОТЕРЯЛА актуальность, т.к. более 50% его замечаний были приняты к сведению и исправлены. Начните с появления в языке garbage collector'а и обеспечения-таки полной абстракции. А ещё ваша попытка приуменьшить его значимость не перекрывает моих отметок в первом посте здесь. Arachnelis (обс.) 19:42, 30 ноября 2016 (UTC)

• Изначально нужно доказательство, что Джойнер является АИ. Пока что этого не наблюдаю. Bsivko (обс.) 20:14, 30 ноября 2016 (UTC)
• Чтобы было более понятно: см. ВП:ЭКСПЕРТ. Можно обсудить на ВП:КОИ, если желаете — там оценку дадут более опытные участники. Bsivko (обс.) 22:45, 30 ноября 2016 (UTC)

• критика шаблонов C++ - там есть неубиенные. Попробуйте составить предложение по сабжу, которое бы вас устроило, может, так быстрее закончим. А то, я смотрю, вы весьма недвусмысленно ставите себя бОльшим католиком, чем Папа Римский. На всей планете авторитетный, а на рувики нет. (и всё же: чтобы укорачивать достоинство критикующего C++, вам надо сперва показать, что у Страуструпа оно висит ниже колен. Он вообще-то сам никто.) Arachnelis (обс.) 04:53, 1 декабря 2016 (UTC)

• При чем тут шаблоны? Речь шла о Джойнере, т.к. это непонятно кто. Bsivko (обс.) 17:13, 1 декабря 2016 (UTC)
• Джойнер? Заслуженный критик C++. Авторитетности более-менее хватит для соответствующего раздела статьи о соответствующем языке. Внутривикипедейное «сравнение мужей» производится по очень простой схеме — Страуструп издаётся и переиздаётся на языках всего мира, а по количеству интервью с ним он может потягаться со средней величины рок-звездой, Джойнер — самиздат широко известный в узком кругу. По количеству ссылок в школяре разница — на порядки. Про миллион мух, конечно, можно послушать, вот только ВП:ИСТИНА --be-nt-all (обс.) 17:42, 1 декабря 2016 (UTC)

• Несколько истин и следствий из них. 1) Популярность никак не свидетельствует о близости к истине. Напротив, как говорил Лев Толстой, "Заблуждение не перестаёт быть заблуждением от того, что большинство разделяет его". Отсюда (из факта, не из признания Толстого за Обладателя Вселенской Истиной) всякий фольклор про "миллионы мух". 2) C++ небезопасный язык. Следовательно, случайная программа на нём с вероятностью в 99,(9)% содержит ошибку, следовательно, если стоит требование отказоустойчивости (а по мнению маниакально-депрессивных педантов вроде меня тех, для кого оно не стоит по дефолту, надо как минимум гнать из программирования поганой метлой), то дешевле отказаться от него, чем отлаживать и статически анализировать. 3) Eiffel - дисциплинированный язык, по безопасности и при том гибкости стоит на полпути от Си к ML. Следовательно, любой фанат этого языка как минимум дисциплинирован в программировании. Следовательно, если он критикует некоторый язык, то это как минимум является веским основанием для проверки критикуемого языка на адекватность присутствия в индустрии. (это верно для любого дисциплинированного языка). 4) Страуструп - не специалист в области информатики, его нельзя ставить рядом с Хоаром, Дейкстрой или ещё кем, единственно, чем он отметился в истории - тем, что взял чужое творение и начал менять его по схеме "лягушка в кипятке". Следовательно, он подлец. Коммерсант-жлоб, готовый утопить весь мир в отвратительного качества ПО ради самовозвышения и обогащения. 5) Не факт, просто отделяю. Общий вывод из приведённых фактов - критика Джойнера имеет полное право противопоставляться популярности C++. Arachnelis (обс.) 21:18, 7 декабря 2016 (UTC)

• Oh Mein Gott. @Arachnelis: я вообще дал ссылку на эссе про истину в надежде про то, что вы его прочитаете и поймёте, что мы ИСТИНУ не ищем, а отражаем более-менее устоявшиеся т.з. Ваши высказывания про Страуструпа сильно далеки от ВП:СОВР ну и истине-то как-раз не соответствуют. Просто Бьёрну ещё в студенческие времена понравилась идея ООП в Симуле, но после того, как ему пришлось код курсовой/диссера (уж не помню на вскидку чего именно) переписывать с красивой симулы на страшный Fortran|PL/I|ассемблер (опять же деталей на память не помню) из-за проблем с быстродействием, он решил сделать ООП максимально близкий к машинному уровню. То, что на Страуструпа в студенческие времена ещё и Algol-68 произвёл впечатление, впрочем, отдельный вопрос. А вообще, помню кусочек из чьих-то мемуаров, о том, как в AT&T показывали на лабораторию Страуструпа, со словами — а вот тут сидит чудак, который думает, что разрабатывает язык программирования, на котором будет писать весь мир. Он своё творение миру предложил, мир его принял. «Кресты» будут считаться мейнстримом, а не legacy, пока не появится «та молодая шпана, которая сотрёт его с лица земли». На данный момент неплохие шансы у Mozilla Corporation с их Rust'ом (кстати, вы не в курсе, почему разработанный всё в той же AT&T Cyclone настолько не взлетел? --be-nt-all (обс.) 21:47, 7 декабря 2016 (UTC)

• Вы никоим образом не опровергли мои слова. "Пахал" - не значит делал по уму. Сравните с Милнером и Харпером - вот где Информатика с большой буквы. А Cyclone пипл не хавает по вполне понятным причинам - сама идея проекта - принудить низкоуровневых маньяков заняться параноидальной выверкой программ. Он не претендует на прикладные разработки, как C++. В итоге - производительность труда ниже, чем у высокоуровневых языков, а маньяков в принципе ни к чему принудить нельзя, они - Жрецы Тайного Знания, что хотят, то и воротят. Такие технологии можно продвигать только законодательно, как в СССР. На свободном рынке они всегда будут "просто очередной хорошей идеей". Arachnelis (обс.) 21:56, 7 декабря 2016 (UTC)
• (доп) Чтобы новый язык победил имеющийся по популярности, необходимо соблюдать общеполитическое правило: если что-то ограничиваешь, компенсируй это щедрыми улучшениями где-то ещё. Для практиков "где-то ещё" находится в строго определённом месте: повышение производительности труда. Cyclone пусть и ненамного, но сложнее и многословнее, чем чистый Си. А вот в Rust указанное правило торжествует. C++ же использует другой принцип (не могу применить к этому слово "правило"): дай людям всё подряд, а если начнут жаловаться на избыток свободы, обвини их самих в бессовестной жажде потребления. С точки зрения личного профита путь выигрышный; с метасистемной и моральной точек зрения - разрушительный. Arachnelis (обс.) 22:14, 7 декабря 2016 (UTC)

• Ок, понял, хотя в циклоне появился достаточно новый для тогдашнего мейнстрима вывод типов. Хотя, может, для того времени, чересчур новый. --be-nt-all (обс.) 22:36, 7 декабря 2016 (UTC)

• (доп2) Полагаю, я обязан также дать АИ на свой "пассаж" про "жлоба". Сейбел "Кодеры за работой" 2009. Глава 12 "Кен Томпсон". страница 414. Описанное эмоциональное поведение Страуструпа НУ НИКАК не удаётся назвать "математически выверенным доказательством своей правоты". Отчётливо видно толи ущемление самолюбия, толи риск огромных финансовых убытков, толи и то и другое одновременно.Arachnelis (обс.) 22:31, 7 декабря 2016 (UTC)

• Гляну --be-nt-all (обс.) 22:36, 7 декабря 2016 (UTC)
• Глянул. Ущемлённое самолюбие да, видно. А про «риск огромных финансовых убытков» в то время, когда C++, только шёл на взлёт, простите смешно. Оно и сейчас то сомнительно (Страуструпу грозит разве что потеря гонораров от книг и прочего, что было-бы для него проблемой, но это не «огромные финансовые убытки») и вообще, основной бизнес вокруг C++ это книги (ага, про правильное костылестроение), и инструменты вроде en:PVS-Studio и Coverity, на фоне того же бизнеса вокруг linux смотрится это всё откровенно бледно. И в любом случае указанная вами сноска явное нарушение вами ВП:СОВР никак не оправдывает. --be-nt-all (обс.) 00:53, 11 декабря 2016 (UTC)

• Вам режет глаз слово "жлоб"? Замените на "человек, ставящий свою прибыль превыше легко прогнозируемого системного влияния своих действий на развитие науки и общества". Возможно, для вас разница и существенная, а для общества, в котором я вырос и работаю, она равна нулю, только второй вариант излишне длинный и трудоёмкий в написании и прочтении. Когда тебя окружают уважаемые люди с учёными степенями и множеством регалий, которые на совещаниях не стесняясь обсуждают рабочие вопросы полуматерным языком, сознательные границы представления об "интеллигенции" сильно меняются, а это влечёт и сдвиги в подсознательном отношении к понятию "культуры речи". Начинаешь больше обращать внимание на то, что сказано, а не как. В статьях я пишу аккуратно, точно и грамотно — претензии пока никто не предъявлял. А в обсуждении сократить сто двадцать три буквы до четырёх весьма удобно. Arachnelis (обс.) 18:19, 19 декабря 2016 (UTC)

Отклонения от темы авторитетности Джойнера в этой ветке и нарушения НЕТРИБУНА и СОВР вообще будут вести к прогрессивным блокировкам участников дискуссии. — Ле Лой 05:55, 20 декабря 2016 (UTC)

• А где надо доказывать, что я не нарушал правила, если меня в этом обвиняют? (в общем случае, когда приходится уклоняться от темы ради такого доказательства) Arachnelis (обс.) 17:11, 20 декабря 2016 (UTC)

труЪ авторитеты

• В общем мораль сей басни такова, критикуя C++ тут, надо ссылаться на таких людей, как тьюринговский лауреат Никлаус Вирт (или любой другой тьюринговский лауреат) или лауреат премии Дала-Нигарда и ACM Software System Бертран Мейер. Ну, или (даже лучше), кто-то из знаменитых практиков soft-индустрии. Ян Джойнер или, к примеру, Крис Касперски (см. ветку выше) не подойдут. --be-nt-all (обс.) 22:36, 7 декабря 2016 (UTC)

• Такой вариант: "популярен, хотя многие авторитетные эксперты в области информатики считают его технически ущербным и возражают против его применения" [обзор Сейбела][Торвальдс][Столлман][Реймонд][Кнут][Гай Стил][Вирт]. Годится? Arachnelis (обс.) 15:23, 10 декабря 2016 (UTC)

• Или, если более достоверно (а то уж тут не знаешь, как обобщать, чтобы тебя не обвинили в ориссе): "... считают плохим[Кен Томпсон][Пол Грэхэм], кошмарным[Торвальдс], уродливым[Столлман], пестрящим противоречиями[Кнут], создающим сложности как тем, кто использует его, так и тем, кто его реализует[Скотт Майерс], наносящим вред сознанию программистов[Эрик Наггум], основанным на исходно неправильной идее и единственным языком, на фоне которого Кобол выглядит привлекательным[Бертран Мейер]". Arachnelis (обс.) 19:57, 10 декабря 2016 (UTC)

• Ну Торвальдс, зная его, мог бы и как-нибудь матерно выразиться, а Столлман говорить-то может всё что-угодно, но до появления clang'а, разрабатываемый под его руководством gcc был околоэталонной реализацией плюсов. Что до Эрика Наггума, он как-то не выглядит фигурой того-же уровня, да и ссылки на откровенный форум нам не сильно нужны. Но в варианте считают плохим^{[Кен Томпсон][Пол Грэм][Торвальдс]}, переусложнённым^{[Скотт Майерс] (где вы нашли у него что-то иное)} и пестрящим противоречиями^[Кнут], а Бертран Мейер даже назвал его не только основанным на исходно неправильной идее но и единственным языком, на фоне которого Кобол выглядит привлекательным — почему нет. --be-nt-all (обс.) 22:01, 10 декабря 2016 (UTC)

• Во-первых, давайте вы пока не будете зарубать авторитетные источники. Вот уж где точно нужен консенсус большого числа участников, чтобы заявить "нет, этому авторитету не видать упоминания себя на вики как своих ушей!!!". Тем более, что речь идёт не о единственном источнике к спорному утверждению, а об одном из ТРИНАДЦАТИ (!) источников (ещё Дейкстра не упомянут), разными словами опускающими язык до безнадёжно низкого уровня. Я составлю из всего доступного списка, и буду удивлён, если консенсус реально решит вот так взять и вырезать. Во-вторых, вы не указали, стоит ли писать скомпилированно, или по частям. Arachnelis (обс.) 23:50, 10 декабря 2016 (UTC)

• А давайте вы не будете переходить на holywar тон там, где это не уместно? Вы ещё не уловили закономерность, чем обычно заканчиваются ваши обращения к широкому кругу участников? А по сути — Столлман (а) в отличие от Торвальдса давно сам не программирует (б) известен отнюдь не этим, и, самое главное «плохой, кошмарный, уродливый» через запятую — это элементарное дурновкусие и отнюдь не энциклопедический стиль. Хотите добавить R.M.S. в список сносок после плохой, добавьте, но как по мне это утверждение не усилит, а только ослабит. По Мейерсу я нашёл в источнике то, что нашёл, на то что нашли вы дайте пожалуйста точную цитату. Если же «зарубленный» АИ, это en:Erik Naggum — простите, но совсем не понятно как он вообще попал в эту компанию, а с учётом того, что второе предложение преамбулы викистатьи о нём гласит «Since the early 1990s he was also a provocative participant on various Usenet discussion groups» — то нам ссылаться на одну из его форумных провокаций ну совсем-совсем no way. А предложенный мной компромисс (причём сразу после адекватного описания Кобола) уже будет смотреться достаточно сильно --be-nt-all (обс.) 00:28, 11 декабря 2016 (UTC)

• Вот как раз сейчас я на холивар не переходил. Я против зарубания Торвальдса. Наггум, согласен, в этом ряду смотрится несколько менее авторитетно, но, повторюсь, так как он лишь один из известных людей здесь (заметьте, достаточно известных, чтобы про него написали вики-статью), а не единственный, его ещё надо постараться выбросить из цепочки. Я пока даю строго разделённое цитирование, чтобы, повторюсь, избежать уже надоевших обвинений в ориссе. C++ поливаю грязью не я один в целом свете, а Вон Какие Люди. Если здесь будет консенсус о слиянии каких-то реплик в обобщённую, или вообще компиляция типа «хомячков от C++ прёт, а зубров от него тошнит» — пожалуйста. Я проделал огромную работу по сбору источников, но бюрократия меня утомила. Слова Мейерса: «Such complexity affects more than just people who write programs in C++. It also affects people who want to write tools that analyze C++ programs. One of the reasons why there is a relative dearth of tools such as refactoring browsers for C++ is that C++ is just so darned complicated.» Arachnelis (обс.) 01:14, 11 декабря 2016 (UTC)

• Собранный вариант:

  C++ является одним из самых популярных языков программирования сразу по многим параметрам, хотя многие авторитетные теоретики и практики информатики отзываются о нём резко негативно: его считают плохим (Кен Томпсон, Пол Грэм), кошмарным (Линус Торвальдс), уродливым (Ричард Столлман), омерзительным (Джейми Завински), несуразным (Дональд Кнут), раздутым, запутанным, неуклюжим, негибким, хрупким (Эрик Реймонд), сложным в использовании и в реализации (Скотт Майерс), принципиально небезопасным и неверифицируемым (Никлаус Вирт), основанным на исходно неправильной идее (Бертран Мейер) и всестороннем притворстве (Гай Стил) и единственным языком, на фоне которого Кобол выглядит привлекательным (Бертран Мейер). Кроме того, утверждается, что он вреден для мозга и искажает познавательные функции разработчиков (Эрик Наггум, Никлаус Вирт, Эдсгер Дейкстра), и что программы, написанные на C++, склонны наследовать все его плохие качества (Эрик Реймонд).

• Arachnelis (обс.) 01:14, 11 декабря 2016 (UTC)

• No Way. Это однозначно текст не для энциклопедии. Вот не надо сюда нести все эпитеты ведущегося holy war’а и Наггуна, которого даже в некрологе помянули как форумного провокатора (если вы внимательно посмотрите статью в англовике там про это написано примерно в полтора раза больше, чем о его заслугах как лисп-программиста). Я ведь не «зарубал» Торнвальдса, я просто сказал, что он может в дискуссии спокойно использовать и что-нибудь непечатное (будете спорить?), и ссылаясь на него совсем не обязательно дословно повторять эпитет. А «я пока даю строго разделённое цитирование, чтобы, повторюсь, избежать уже надоевших обвинений в ориссе» это (с учётом результата) сильно напоминает ВП:НИП и ВП:НДА --be-nt-all (обс.) 01:32, 11 декабря 2016 (UTC)
• Such complexity affects more than just people who write programs in C++ в тексте, на который вы ссылаетесь, этих слов нет, только «I’d like to answer this question with 'complexity, complexity, complexity!', but naming the same thing three times is cheating. Still, I think that C++'s greatest weakness is complexity.» ну и дальше конкретные примеры сложностей. --be-nt-all (обс.) 01:37, 11 декабря 2016 (UTC)

• Так я же сказал: вот вам материал, добытый потом и кровью, берите и печатайте по местным нормам. А Столлмана и Наггума убирать я против по той причине, что они - ЛИСПЕРЫ. Пол Грэм писал, что Лисп - самый мощный язык из существующих, так что всякий хакер на нём априори крут. Цитату Мейерса гуглил из личной коллекции по клочку, поэтому промахнулся. Вот здесь встречается, если страница годится. Если нет - гуглить по точному совпадению хоть какого её фрагмента. В сборке переставил местами пару фраз. Arachnelis (обс.) 01:58, 11 декабря 2016 (UTC)

• Некто Джек, по его словам цитирует Мейерса, в комментарии к блогозаписи Саттера? Это источник? В первом источники тоже была цитата, но хоть с указанием откуда. Что Столлман и Наггум — лисперы, замечательно — я их emacs-ом пользуюсь, но вот то, что написано о Наггуме попросту исключает его из числа АИ совершенно. Сноску на RMS оставить можно, если хотите. В любом случае финальная фраза должна быть достаточно краткой и более-менее близкой к предложенному мной варианту. --be-nt-all (обс.) 02:29, 11 декабря 2016 (UTC)

• Прошла неделя, а вы ни оригинал интервью не нагуглили, ни фразу не подобрали? Будете ждать от меня потока вариантов, которые вы сможете благополучно зарубать? В этом ваша обещанная помощь? Arachnelis (обс.) 18:38, 16 декабря 2016 (UTC)

• Нда. Я понимаю, когда в качестве критики плюсов приводят скажем, std::fstream не понимающий utf-8 имена файлов и вообще не компирующийся при попытке сунуть в него utf-16 имена. Но приводить в качестве образца критики Торвальдса, с той самой цитатой "C++ - говно! Кто не согласен - говноед!"... Zero Children (обс.) 19:42, 11 декабря 2016 (UTC)

• Именно Торвальдс в этом аспекте чрезвычайно важен - его громкий, обогнувший эхом планету, вопль - это такой большой кроваво-красный стоп-сигнал для любого, кто посмеет заикнуться, что C++ подходит для низкоуровневого программирования. Есть ряд более техничных и безэмоциональных источников, объясняющих, почему C++ туда не подходит, но на них посмотрят лишь уже заинтересовавшиеся подробностями. Торвальдс же - идеальный мотиватор, ибо известно, насколько он шарит в этой теме. Arachnelis (обс.) 18:38, 16 декабря 2016 (UTC)

• Нет, это такой большой кроваво-красный сигнал "Ахтунг! Неосилятор в треде!". Говорю как человек видевший попытки применения "стоп-сигнала". Аргументация же осиляторов строится совсем не на "а вот Торвальдс крыл язык матом!!!ОДИНОДИНОДИН". И зачастую касается недостатков общих и для плюсов, и для Си. Zero Children (обс.) 21:54, 22 декабря 2016 (UTC)

COBOL

• Ветка отсюда.

Arachnelis, т.е. вы из этого

In his letter to an editor in 1975 entitled "How do we tell truths that might hurt?" which was critical of several of COBOL's contemporaries, computer scientist and Turing Award recipient Edsger Dijkstra remarked that "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."

получили это

Следует заметить, что высокие оценки по этим показателям не только никак не свидетельствуют о высоком техническом уровне языка и/или оптимизации расходов при его использовании, но и напротив, порой могут говорить об обратном. Например, язык Кобол входит в число лидеров по количеству написанных на нём строк кода, но причиной этому является крайне низкий показатель модифицируемости кода, что делает этот код не повторно используемым, а lecacy-кодом[en] — как следствие, поддержка программ на Коболе в кратковременной перспективе обходится значительно дороже, чем программ на большинстве современных языков, но переписывание их с нуля потребовало бы значительных единовременных вложений, и может сравниваться только с долговременными расходами

я правильно понимаю? или я что-то упустил? Bsivko (обс.) 22:48, 7 декабря 2016 (UTC)

• Нет. Я сперва написал ФАКТ, а когда у меня спросили источник вместо того, чтобы просто его найти и прилепить, я прилепил первый попавшийся источник из хорошей английской статьи по вопросу, не читая. Уж не хотите ли вы сказать, что неподдерживаемость программ на Коболе вызывает у вас сомнения? Если нет, и если вы хотите улучшить энциклопедию, а не разрушить - окажите милость, поищите источник сами. (доп) Я провожу очень серьёзное различие между фактами и тем, что кто-то где-то этот факт словами выразил в документе того уровня, на котором он проходит по критериям вики. Возможно вас это удивит, но даже в серьёзной науке есть "общеизвестные" места, в подтверждение которым мне не удаётся найти конкретный АИ. Мелькает повсеместно, а формально никто не определяет. Иногда это заканчивается обнаружением очень свежего документа, где кто-то подрудился-таки написать определение, очевидно, специально чтобы его можно было процитировать на вики. Arachnelis (обс.) 09:28, 9 декабря 2016 (UTC)

• Я был столь любезен, что почитал по-внимательнее англо-вики-статью, нашёл в ней более добротные источники, проверил их содержимое и поместил сюда. И всё это сам! Незачто! Arachnelis (обс.) 21:29, 9 декабря 2016 (UTC)

• По последней правке, о непривличении экспертов при разработке Кобола, у будущего Тьюринговского лауреата Джона Бэкуса Фортран не сильно красивее вышел, при этом для работы с нечисловыми данными в отличие от не подходил от слова совсем (попытка №2, т.е. Algol-58/60 — тоже, а Simula, виртовский Algol-W (будущий Pascal) и Algol-68 — это уже на десятелетие позже). Может проблема была в том, что в 1950-х гг. экспертов в области информатики ещё не существовало в природе, а разработка и реализация любого языка программирования была подвигом? Точно ли в источнике написано именно это, а если это — стоит ли такое утверждение к нам нести? --be-nt-all (обс.) 01:10, 10 декабря 2016 (UTC)

• Субъективно я согласен, последнюю фразу можно и убрать. Однако, в статье Коболу противопоставляется APL и вроде мелькает личное мнение его создателя Айверсона, да и Лисп уже существовал. Кроме того, там упоминается, что многие решения в Коболе связаны с недоразвитостью технологий компиляции, и через десяток лет, когда технологии развились, от него были все основания отказаться. Ну просмотрите статью, выберите короткую мысль на свой вкус. Мне кажется, мы уж очень закопались здесь в детали - нам всего-то и требуется, что на паре примеров противопоставить популярность и технический уровень языков. Arachnelis (обс.) 15:17, 10 декабря 2016 (UTC)

• Ну случай APL и LISP отличает то, что и Кен, и Джон были чистыми математиками, реализацией озаботились их ученики/младшие сотрудники, и да, это их от Fortran и Cobol действительно отличает, но LISP не даром потянул за собой специализированное железо (я читал достаточно красноречивые материалы об «эффективности» перволиспов на тогдашних «массовых» ЭВМ) а APL и его прямые потомки считаются эталонными «эзотерическими языками, применяемыми в продакшене». И да, до того как в APL внедрили взятые извне структурные операторы, там использовался вычисляемый goto по номеру строки (sic!), APL-way конечно в избегании ветвлений, но в исходном «китайском бейсике» они были реализованы воистину кошмарно. В общем хорошо, гляну что с эти можно сделать. --be-nt-all (обс.) 22:15, 10 декабря 2016 (UTC)

• Нет. Я сперва написал ФАКТ, а когда у меня спросили источник вместо того, чтобы просто его найти и прилепить, я прилепил первый попавшийся источник из хорошей английской статьи по вопросу, не читая. — правильно ли я понимаю, что в статьях вы сначала пишете что думаете о предмете, и потом ищете под это источники, подтверждающие ваше мнение? Bsivko (обс.) 07:19, 11 декабря 2016 (UTC)

• Неправильно, и нечего играть словами. Я вам "факт", а вы мне "мнение". Я сначала пишу то, что ЗНАЮ по предмету, а потом ищу ПЕРВОисточники, из которых это знание когда-то взялось непосредственно у меня или у того, от кого я это знание перенял. Более того, я не скрывал этот метод с самого начала, и претензий не получал, и результат всех устраивает. Если для вас это радостный шанс срочно зарубить всю мою работу, т.к. её изучение вашим начальником рискует дискредетировать вас в его глазах - можете приступать. Начните с ярчайшего примера работы, которую я выполнил именно в такой последовательности - полиморфизм (информатика). Статья - сущая субъективность, как видите, так и просится на КУ. Arachnelis (обс.) 19:21, 13 декабря 2016 (UTC)

• Именно так подают своё мнение разного рода уфологи и экстрасенсы: сначала озвучивают то, что ЗНАЮТ на основе того, что прочитали, увидели краем глаза, или заметили «неслучайное» совпадение, а потом ищут доказательства своей правоты. И про «претензий не получал» врать не надо: а как же тогда вы лишились флага автопатрулируемого?--Tucvbif???
  * 19:17, 23 декабря 2016 (UTC)

• @Tucvbif:, коллега, помните про ВП:ЭП. Коллегу Arachnelis иногда заносит (и тема заноса называется C++, ну и про серебряной пули нет он, кажется, склонен забывать), но чтобы написать приличную статью на мало-мальски обзорную тему, надо именно сначала выстроить некую картину в голове, а потом уже строить под неё опору из источников. И если коллега порой откладывает сбор источников на потом, ещё не повод бросаться столь серьёзными обвинениями. --be-nt-all (обс.) 11:12, 29 декабря 2016 (UTC)

• Проблема отчасти в том, что участник ненавидит C++ и любит ФП. В таких условиях его правки могут проводиться только при наблюдении других. Иначе получаем то что получаем: оригинальный синтез и нарушения ВП:ВЕС. А также прочую аттрибутику холиваров на тему ЯП. Bsivko (обс.) 23:10, 17 января 2017 (UTC)

• Переношу со своей СОУ, пока ещё не на правах наставника, но по ВП:ИВП и под свою ответственность реплику коллеги Arachnelis о серебряной пуле и роли ЯП в работе программиста:
  • ФП не является серебряной пулей в терминологии Ф.Брукса, я никогда не говорил обратного. Брукс определил серебряную пулю как «технологию или методологию, одно только использование которой повышает производительность труда минимум на порядок». Увы, если вы пересадите махрового фортраниста или коболиста на Хаскел, вы не только не получите прироста — вы потеряете: см. The Evolution of a Haskell Programmer. И Пол Грэм в «beating the averages» очень чётко это описал: если вы пишете на Коболе, то все самые мощные фичи Лиспа покажутся вам ненужными заумностями, и вы не будете их использовать. Он ввёл собственный термин «the Bulb paradox», но по сути заново переоткрыл гипотезу Сепира-Уорфа (я на себе прочувствовал его мысленный эксперимент задолго до того, как прочитал его статью — при переходе с Турбо-Бейсика на Си-с-Классами). ФП может показывать прирост на порядок, и не на один, но только при очень глубоком его знании; только при использовании таких подходов к проектированию, которые только становятся возможными при уверенном владении логикой высшего порядка, но не рождаются сами в уме при одном взгляде на fold; только при использовании не менее развитой инфраструктуры, устраняющей собственные вторичные сложности, присущие ФП (например проблемы с FFI); и только на достаточно крупных проектах (не на студ.лабах). Каждое из этих условий далеко вываливается за тезис Брукса. Я очень уважаю СПН и нисколечки с ней не спорю (напротив, когда он далее обсуждает реакцию общественности на свою статью, меня поражает недалёкость его оппонентов). Вы, видимо, забыли, но я даже написал об этом в статье — добавьте туда «…коэффициента повторного использования (см. серебряной пули нет) — определяющим фактором…». Другое дело — C++. Я потому его и ненавижу, что он вводит в программирование вторичных сложностей на три порядка больше, чем существенных, а предъявляет полученный монолит как «объективную сложность программирования». Но и это не означает, что переход с него на что получше после большого опыта разом даст прирост даже на порядок — слишком много вредных привычек придётся выбивать из своей головы. Мораль Брукса многие не замечают даже после того, как он повторно выделил её во втором издании МЧМ в главе «новый выстрел СПН». Помните? «Даже если бы все без исключения считали „СПН“ пессимистической, что в этом худого? Является ли утверждение Эйнштейна о том, что ничего не может перемещаться со скоростью, большей скорости света, „унылым“ и „мрачным“? А как насчет результатов Геделя о том, что некоторые вещи невычислимы?». Моя позиция не связана с унынием по поводу СПН, она связана с гипотезой Сепира-Уорфа. Для меня более мощный язык — это более мощное мышление (ещё раз оглянемся на Пола Грэма), так что смена языка не заряжает пистолет разработчика серебряной пулей (которой можно было бы сразу выстрелить), а запускает процесс перезарядки мозгового реактора новым типом плазмы, что в дальнейшем (по окончании процесса перезарядки) открывает его кораблю новые степени свободы и повышает разрешающую способность координатного позиционирования, влияя на продукт его труда. Но эта плазма сливается с реактором в единое целое, и её нельзя просто выкачать и закачать в другой реактор — она всегда адсорбируется по месту, и это требует времени, и она не усваивается в ржавом реакторе. А следовательно (и вот с этим как раз связана вся моя ярость в популяризации ФП) запускать процесс зарядки надо как можно раньше. Arachnelis (обс.) 21:08, 17 января 2017 (UTC)
• Спасибо за внимание, напомню, реплика перенесена под мою ответственность, с моей СОУ (на которую вроде топик-бан не распространяется) и, тем самым обходом топик-бана не является --be-nt-all (обс.) 21:46, 17 января 2017 (UTC)

Поколения языков программирования

Есть такая статья. Предлагаю перенести туда всё, что относится к поколениям языков программирования (включая источники), чтобы не было дублирования информации. Oleg3280 (обс.) 17:28, 17 декабря 2016 (UTC)

• Против. Обзорная статья должна быть обзорной и читаться как единый текст. Если статья о поколениях языков слишком мала (а это так) — это вопрос расширения той статьи. Тут же всё в порядке, после того, как статья про поколения будет доведена (хотя бы) до нынешнего уровня этой статьи, нужно будет воспользоваться шаблоном {{main}} и, возможно, сократить какие-то детали, но механическое разделение будет только резанием статьи по живому be-nt-all (обс.) 10:59, 29 декабря 2016 (UTC)
  • Понял. Значит я ошибся. Oleg3280 (обс.) 15:13, 29 декабря 2016 (UTC)

ЗЛВ

Обсуждение шаблона:Знаете ли вы/Архив/8#Качество программного обеспечения
Я думаю, что качество программного обеспечения определяется исключительно квалификацией программиста, его знаниями и умениями, а не выбором языка программирования или бюджетом. Я не являюсь профессиональным программистом, поэтому могу ошибаться. Но эта точка зрения основана на интуиции и здравом смысле. Oleg3280 (обс.) 18:57, 26 декабря 2016 (UTC)

Эм... На примере готовки супа. Perl-суп - первой командой вы ставите на плиту красную кастрюлю. Второй командой по ошибке кладете овощи в черную кастрюлю, которая материализуется сама собой неизвестно откуда. Третьей командой вы зажигаете огонь под пустой красной кастрюлей, которая после этого распаивается на части. Тем не менее, это не считается аварийной ситуацией и повар с невозмутимым видом водит пустым половником по остаткам кастрюли. C++ суп - при попытке положить овощи в черную кастрюлю, перед вами появляется шеф-повар и ругается "нет у меня таких кастрюль, идиот!". Однако, при попытке налить в кастрюлю двадцать литров воды, тот же повар молча опрокидывает на плиту ведро и пытается варить суп дальше. Все это формально не считается аварийной ситуацией, но через час происходит взрыв газа утекшего из погасшей плиты. Ассемблер-суп - вы отсылаете повару длинный список химических формул ингредиентов, где вместо H2O, по ошибке написано H2O2. После этого вы попадаете в больницу и три дня пытаетесь понять в каком месте опечатались.

Вот, собственно, такие нюансы и приводят к тому что качество программного обеспечения зависит в том числе от выбора языка. Zero Children (обс.) 19:30, 26 декабря 2016 (UTC)

• Снова на ЗЛВ --Sunpriat (обс.) 11:22, 29 декабря 2016 (UTC)
• Качество программного обеспечения зависит от многих факторов, среди которых, в том числе, выбора подходящего языка программирования. Однако если ранжировать эти факторы, то выбор языка программирования, как правило, будет в хвосте списка. Разумеется, всегда можно придумать примеры, когда неверный выбор языка может не просто понизить качество ПО, но и привести к краху весь проект. Скажем, выбор языка ассемблера при разработке крупной корпоративной информационной системы. Но это будут такие примеры, в которых всё слишком абсурдно, чтобы иметь отношение к реальности и заслуживать внимания. Примерно так же абсурдно и далеко от реальности, как и то, что написал выше коллега Zero Children. Однако и коллега Oleg3280 ошибается, говоря, что «качество программного обеспечения определяется исключительно квалификацией программиста». Обеспечение качества — это сложная системная задача, это давно поняли в промышленности вообще, и в программной индустрии в частности. Даже самый квалифицированный программист не сможет скомпенсировать скверно спроектированную архитектуру, а самая гениальная архитектура будет бесполезна при неверно сформулированных требованиях. И так далее. Евгений Мирошниченко 11:41, 29 января 2017 (UTC)
• P.S. Почитал по заглавной ссылки некоторые реплики коллеги Arachnelis. Я со многими не согласен. Например:

  >«программы на некоторых языках физически не способны глючить»: это из области юмористической фантастики, но в любом случае, «неспособность глючить» — это всего лишь одна из составляющих безотказности, которая является составной частью надёжности, которая является лишь одним из многих факторов качества.

  >«Безопасные языки обеспечивают надёжность»: всего лишь повышают, но не гарантируют. Даже если язык гарантирует, что ошибка в коде не приведёт к краху системы, это ещё не гарантирует надёжности. Скажем, зацикливание программы по прежнему возможно (оно теоретически не считается крахом системы), а оно является отказом: система не выполняет функцию так, как надо. Кроме того, нередко прикладная программа является лишь частью всей системы, в которую могут входить, скажем, ПО серверной части (например, базы данных), а надёжность одной части системы не является гарантией надёжность всей системы. Наконец, любой язык лишь инструмент, он может предоставить средства, но не может гарантировать, что они использованы в полной мере и правильно. Поэтому никакой язык на гарантирует, что на нём написали правильно: использовали правильные типы, правильно описали предусловия/постусловия и инварианты, реализовали проверку всех возможных ошибок/исключений при работе с внешними системами; собственно, правильно реализовали правильные алгоритмы. Евгений Мирошниченко 12:46, 29 января 2017 (UTC)

Анонсирование на ЗС

В ноябре-2016 статья была переработана, расширена (до 113 Кб) и номинирована на СП ЗЛВ:

* Качество программного обеспечения по измеримым показателям гораздо достовернее определяется выбором языка программирования, нежели уровнем финансирования проекта. Arachnelis (обс.) 11:05, 18 ноября 2016 (UTC)

Сокращённый вариант взял Deinocheirus в свой «выпуск 23 декабря», но вскоре после появления на ЗС анонс скрыл DZ, начавший обсуждение своей правки на СО шаблона, где появился новый вариант с другим фактом:

* Кто не хочет выкидывать мусор сам, тот использует высокоуровневый язык программирования--Saramag (обс.) 14:37, 24 декабря 2016 (UTC)

Этот вариант из черновика «29 декабря (в складчину)» удалила Victoria, поэтому его не было в шаблоне на ЗС.

Следущая серия эпопеи продолжилась в январе-2017. Обсуждение открыто шло на СО СП → «Качество ПО зависит от ЯП больше, чем от бюджета» и на СП → «Язык программирования», где в итоге был предложен новый вариант, согласованный участниками Saramag, Be nt all и Arachnelis:

* Чем больше у тебя языков, тем быстрее заработает твоё творение.

Этот консенсусный вариант был взят в черновик Кубаноида → «выпуск 25 января». Но MBH скрыл анонс в шаблоне на ЗС дважды: 26 и 27 января. Подробности в обсуждении на ЗКА: «Закулисные чаты или открытые обсуждения, что важнее?». --DarDar (обс.) 17:56, 1 февраля 2017 (UTC)

• Прототип к последнему предложенному варианту был озвучен 19 января, запись в черновик анонса была выложена 21 января. Таким образом, обсуждение последнего анонса составило менее недели. То, что у анонса есть большие проблемы на профессиональном уровне, было понятно на первой попытке в ноябре. К сожалению, попыток обращения к специалистам (проект ИТ) не было замечено. Как и выверенности утверждения по АИ. Bsivko (обс.) 21:22, 2 февраля 2017 (UTC)
  • Принимали решение о согласованном варианте анонса тоже специалисты. Всех в условиях цейтнота не охватить, сорри. Срок новизны расширенной вдвое статьи истекал 21 января... --DarDar (обс.) 11:19, 5 февраля 2017 (UTC)
• >Качество программного обеспечения по измеримым показателям гораздо достовернее определяется выбором языка программирования, нежели уровнем финансирования проекта. Ну, это просто ложное утверждение, не основанное на источниках. Так что хорошо, что это на ЗС не пустили. «Чем больше у тебя языков, тем быстрее заработает твоё творение» — тоже какие-то выдумки, такому не место на ЗС. Евгений Мирошниченко 04:36, 2 февраля 2017 (UTC)

  Евгений Мирошниченко, Ваших возражений не видно в том обсуждении, где Arachnelis привёл авторитетные источники, подтверждающие его исходную формулировку анонса. Апропо, интерес читателей к статье — стабильно высокий: 597 991 просмотров с июля-2015. Не было на СО шаблона никакого наплыва возражений во время анонсирования статьи 25 и 26 января. --DarDar (обс.) 09:48, 2 февраля 2017 (UTC)

  Дело в том, что я не слежу и никогда не следил за ЗС и ЗЛВ. Поэтому и в обсуждениях не участвовал. Что касается источников, которые коллега Arachnelis привёл, то практически все из них я читал и знаю, и вот что скажу. Коллега Arachnelis написал кучу цитат, что на человека непосвящённого должно производить, видимо, гипнотизирующее воздействие. Однако для человека «в теме» вполне ясно, что ни один из источников не подтверждает формулировку анонса. Более того, некоторые из этих источников утверждают совершенно противоположное тому, что сформулировал коллега Arachnelis. Наконец, скажу грубо, для меня очевидно, что коллега Arachnelis исповедует какое-то своё понимание качества, которое не совпадает с общепринятым. Однако обсуждение на ЗЛВ закрыто, поэтому что толку туда писать, да и зачем? Хотя я мог бы написать целую простыню комментариев, разбирая каждый аргумент коллеги Arachnelis, чтобы показать, что он либо понимается им узко, либо вовсе неправильно, либо не имеет отношения к обсуждаемой теме. Евгений Мирошниченко 10:06, 2 февраля 2017 (UTC)

  Я-то как раз из числа непосвящённых, но гипноз на меня не действует. Имхо, лучше возражать специалистам по месту их утверждений или на личных СО. Если коллега Arachnelis снова станет активным, он ответит. --DarDar (обс.) 10:15, 2 февраля 2017 (UTC)

Ада, Ариан 5

Удалено на след. основаниях:

1. .

   YOU CAN’T BLAME THE LANGUAGE

Ada’s exception mechanism has been criticized in the literature, but in this case it could have been used to catch the exception.

— http://se.inf.ethz.ch/~meyer/publications/computer/ariane.pdf

1. Предсказание Хоара общее и мутное. Также нет ни одного утверждения вторичного источнка что именно это Хоар предсказывал.
2. Не у меня одного такое мнение. Bsivko (обс.) 12:27, 4 февраля 2017 (UTC)
3. Дополнительно см. Авария ракеты-носителя Ариан 5 (4 июня 1996) Bsivko (обс.) 12:28, 4 февраля 2017 (UTC)

Удалено и здесь, на тех же основаниях. Bsivko (обс.) 14:47, 4 февраля 2017 (UTC)

"уровень" языка

• Утверждение об отсутствии в теории понятия об "уровне" было удалено уже дважды - участниками Tau797 и Евгений Мирошниченко. Прошу предоставить источник по теории, который бы описывал эту категорию. Язык определяется как вещь в себе - это "формальная знаковая система", в определении есть только грамматические продукции и т.п., и нет линейки для определения его "уровня". А указывать на подобные расхождения теории с практикой очень важно. Формальный язык. 109.111.21.109 08:41, 3 августа 2018 (UTC)

  Что касается вашего рассуждения о языке как "формальной знаковой системе", то с этим никто и не спорит, но при чём тут теоретическая информатика? Или вы считаете, что теоретическая информатика сводится к спецификациям синтаксиса языков? Я, к примеру, смотрю в лекции по теоретической информатике в СпбГУ и вижу термины "язык программирования высокого уровня" и т.п. В любом случае, если у вас есть ВП:АИ на утверждение «В теоретической информатике нет такого понятия, как „уровень языка“», то для начала приведите его. Без этого разговор не имеет смысла. Евгений Мирошниченко 11:05, 3 августа 2018 (UTC)

  • по законам логики, на утверждение-отрицание не может быть примеров, могут быть только контр-примеры, опровергающие утверждение. Вот банально, открываем Ахо-Сети-Ульмана, самая первая глава "Введение в компиляцию". Цитирую: "Компилятор - это программа, которая считывает текст программы, написанной на одном языке - исходном, и транслирует (переводит) его в эквивалентный текст на другом языке - целевом." Кто кого выше или ниже - в теории не имеет значения. На практике, да, появляется куча трудностей, и об этом пишем в статье дальше. Что касается учебников, что авторства Tau797, что из СПб - русские источники по информатике не авторитетны по определению, это всегда пересказ, и они меркнут рядом с такими именами как Чёрч, Рейнольдс, Жирар, Карри, Хоар, Oleg Kiselov и т.д. и т.п. - кто саму информатику создавал и создаёт. А при пересказе есть такой момент: чем грамотнее человек, тем он осторожнее в формулировках, т.к. сам может задать себе каверзный вопрос; но малейший пробел в знаниях - и в пересказе появляются смысловые ошибки. Например, Tau797 ошибочно отождествляет "декларативные" и "4GL", потому что кто-то когда-то эти термины рядом поставил. Хотя SQL - декларативный, но не 4GL, даже не Тьюринг-полный. upd: Виноват, он перепутал что во что входит. Вот хотелось бы выяснить первоисточник, кто вообще ввёл термины "высокий уровень" и "2-3-4GL"... 109.111.4.22 10:44, 6 августа 2018 (UTC)

Резюме: источников на громкое утверждение у вас нет, теоретическую информатику вы отождествляете с синтаксисом языков программирования (феерично). А в списке с Чёрчем и Хоаром у вас какой-то Oleg Kiselov. Не удивлюсь, если это вы и есть. На сём бессмысленный разговор закончен. Евгений Мирошниченко 13:52, 6 августа 2018 (UTC)

Лжёте: в цитате Ахо-Сети-Ульмана слово "синтаксис" не упоминается. Oleg Kiselov - это Computer Scientist из Калифорнии, один из передовиков информатики сейчас. 109.111.26.110 00:06, 7 августа 2018 (UTC)

Уберите рекламу

"Самые мощные системы статического анализа для них (такие, как PVS-Studio[30][31]) способны обнаруживать не более 70 — 80 %"

В скобках хитро вставлена реклама про программу "PVS-Studio". В других страницах Википедии касающихся языков программирования, мне также встречались, хитрые вставки рекламы от "PVS-Studio". Прошу модераторов провести аудит всех страниц Википедии, где имеется реклама программного обеспечения "PVS-Studio". На самом деле "PVS-Studio" - это заурядное ПО.

— 185.193.196.223 04:22, 11 января 2021 (UTC)

Ошибка

"У Си есть и безопасные потомки, такие как Cyclone или Rust".

Язык программирования Rust не является генетическим потомком языка Си. А синтаксису он скорее алголоподобен. Исправьте пожалуйста ошибку.

— 185.193.196.223 04:27, 11 января 2021 (UTC)